Question-learn-test-feedback pattern to test emerging software construction paradigms

Factory 1 client 1 abstract factory class n concrete factory m abstract products p concrete products p≤ X ≤n*p no Decorator 1 interface 1 component class 1 abstract decorator class n concrete decorator classes nor 1≤ X ≤n Visitor n visited elements (ConcreteElement) p visitors (ConcreteVisitor) no n*p Table 2.1: Excerpt of a testability catalog for design patterns 2.1.2 Understanding the impact of contracts on vigilance and diagnosability Design by Contract ©is a lightweight technique for embedding elements of formal specification (such as invariants, preand post-conditions) into an object-oriented design. When contracts are made executable, they can play the role of embedded, on-line oracles. Executable contracts allow components to be responsive to erroneous states, and thus may help in detecting and locating faults. In this work, we define vigilance as the degree to which a program is able to detect an erroneous state at runtime. Diagnosability represents the effort needed to locate a fault once it has been detected. In order to estimate the benefit of using Design by Contract ©, we formalize both notions of Vigilance and Diagnosability as software quality measures. The main steps of measure elaboration are given, from informal definitions of the factors to be measured to the mathematical model of the measures [87, 86]. As is the standard in this domain, the parameters are then fixed through actual measures, based on a mutation analysis in our case. Several measures are presented that reveal and estimate the contribution of contracts to the overall quality of a system in terms of vigilance and diagnosability. The major results from this study are experimental demonstrations of the benefit of using contracts in order to improve software quality. Figure 2.2 summarizes the impact of contracts on the vigilance of three programs. The global vigilance corresponds to the ratio of errors that can be internally detected by the programs, whereas the isolated vigilance corresponds to the quality of the local contracts of each class. This chart indicates that even the introduction of poor contracts (e.g., that can detect 20% of the errors) on all classes can greatly improve the global vigilance of the program (if local contracts